home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 270 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.8 KB
  1. Path: fido.asd.sgi.com!austern
  2. From: John Max Skaller <maxtal@suphys.physics.su.oz.au>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Cleaning auto_ptr copy semantics.
  5. Date: 05 Feb 1996 09:29:02 PST
  6. Organization: MAXTAL
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <3115374C.1BC7@suphys.physics.su.oz.au>
  9. References: <gregorDLrrun.K2x@netcom.com> <4etq2h$acg@hermes.synopsys.com>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: Mon, 05 Feb 1996 08:46:36 +1000
  12. X-Mailer: Mozilla 2.0b6a (WinNT; I)
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMRY+bUy4NqrwXLNJAQHT3wIAijFpOVG/ohHLTeV1AXhvPmv4kfXdHDvl
  15.     2kx5y5xtX+zaSgO6y4HvrqDKc85FhT1CyF7va1sxI/PBLw8wC2289g==
  16.     =74To
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. Joe Buck wrote:
  20. > 
  21. > gregor@netcom.com (Greg Colvin) writes:
  22. > >The smallest change I can see that preserves the semantics of strict
  23. > >ownership is to separate the concepts of "holding a pointer" and "owning
  24. > >an object", so that more than one auto_ptr can hold a pointer to an object,
  25. > >but only one auto_ptr can own the object.
  26. > 
  27. > Your new proposal is a recipe for dangling pointers.  
  28.  
  29.     It is not Greg's current proposal which is
  30. a recipe for disaster, it is the very notion of using
  31. the copy operator to transfer ownership. IMHO.
  32.  
  33.  
  34. > I don't see a way around reference counts if you want a class that
  35. > contains a pointer and can do copies and assignments using the expected
  36. > semantics and guarantees to clean up the heap object.
  37.  
  38.     I agree completely.
  39.  
  40. > We could still have plain auto_ptr, but with no assignment operator and no
  41. > copy constructor, and with an explicit member function for transferring
  42. > ownership.  This means that a function cannot return an auto_ptr, but it
  43. > could still return one through a reference parameter.
  44.  
  45.     Again, I agree completely, this was my original proposal:
  46. TWO classes, one which was to be used simply to attach heap objects onto
  47. the stack to allow the destructor to delegate to destroying the
  48. heap object. This fixes the problem:
  49.  
  50.     void f() {
  51.         X* x= new X;
  52.         throw 1; // WOOPS, 
  53.         delete x;
  54.     }
  55.  
  56.     Since C++ stack frames are not copyable, copyability
  57. in auto_ptr is not only not required, it's dangerous. The concept
  58. is simply to SCHEDULE deletion at the point of construction:
  59.  
  60.     void f() {
  61.         auto_ptr<X> x (new X); // SCHEDULES DELETION at #1
  62.         throw 1; // OK: invokes block termination code
  63.         // #1: termination code "delete x;" scheduled
  64.     }
  65.  
  66.     This leaves the problem of pointers in copyable
  67. objects -- for which reference counting is a solution
  68. in acyclic cases.
  69.  
  70.     The problem with the "move" semantics of
  71. the current auto_ptr is NOT the strict ownership
  72. idiom -- it's the use of inappropriate copy syntax to
  73. access that idiom.
  74.  
  75.     The solution -- IMHO -- is to ignore and NOT USE
  76. auto_ptr, and take up where the committee failed:
  77. attempt to obtain consensus amoung USERS on suitable
  78. smart pointer classes. "Practice" will then push such
  79. accepted and "in use" classes in to the _next_ standard.
  80.  
  81.     My UESTL/smart module is an attempt to provide
  82. a coherent set of smart pointers. Mail me for a copy,
  83. email comments welcome. [It's unclear if the charter of this
  84. newsgroup allows for "public" comment on my "private"
  85. attempt at standardisation. But the results will be published
  86. in black and white by Prentice Hall. Someone has to
  87. do this, since the committee wasn't able to. The set of
  88. classes I have shows why the committe had trouble: more
  89. than one class is required.]
  90.  
  91. -- 
  92. John Max Skaller               voice: 61-2-566-2189
  93. 81 Glebe Point Rd              fax:   61-2-660-0850
  94. GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
  95. AUSTRALIA                      email: skaller@maxtal.com.au
  96. ---
  97. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  98.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  99.   in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  100.